Is there 100% error free software? Is there 100% secure software? The answer to both questions is NO, but don’t panic. High percentages can be approached if you think about security during the architecture and design preparation phase of your future system, as well as projecting the security perspective into development.
Let’s demontrate an example situation on a quite small company with a focus on financial transactions, which asked these questions. The mentioned company contracted Citadelo to perform a Penetration Test that revealed critical vulnerabilities. “Although a mechanism for user’s input validation is implemented, it is unfortunately not applied systematically and there are places where the developer has forgotten to configure validation. For the hacker, this is the so-called entrance gate. Therefore, we recommend using an existing validation framework rather than custom validations.”, says the penetration tester.
The customer was terrified of the high and critical findings, but after consultation the penetration testers to the developers and fixing the vulnerabilities, the customer was satisfied with the result and so the cooperation continued not only in the next rounds of penetration tests but also in the field of cryptography.
What does the OWASP TOP 2017 Penetration Test consist of: A1 - Injection A2 - Broken Authentication A3 - Sensitive Data Exposure A4 - XML External Entities (XXE) A5 - Broken Access Control A6 - Security Misconfiguration A7 - Cross-Site Scripting (XSS) A8 - Insecure Deserialization A9 - Using Components with Known Vulnerabilities A10 - Insufficient Logging & Monitoring
So, how to apply top security practices during the design and development of web applications:
1) PREPARATION
How to start? When choosing a technology, consider known vulnerabilities (CVEs) and select the technology version that represents minimal risk (according to frequency and criticality of CVEs) - if you can, avoid outdated, “leaky” or unsupported solutions.
To invent a bike? Not necessarily. Include ready-made and proven frameworks = eg a suitable web framework can capture Injections - Hibernate, Spring framework, Angular security.
Is a good architectural design advantageous? Definitely. Classify data sensitivity well and propose adequate security over permissions. Think of roles from the start of development.
Knowledge is the base. Ensure your developers are trained in safety and security development, that Citadelo experts have already realized for several Development departments.
2) DURING DEVELOPMENT
Checking / Supervision from above? A proven mechanism to control the quality of the solution being developed and minimize errors caused by junior developers is to perform a regular code review and determine a responsible Architect who will validate any new additions to the repository (Gitlab, SVN) - thereby identifying weaknesses at the beginning and during development.
Don’t trust anyone. Data: The big mistake is the assumtion that the data provider has validated the input data. Develope the validation of the data transmitted between components in the form of no-trust - eg, do not rely solely on client-side validation but always validate inputs and outputs to potentially dangerous characters on the server-side/back-end (Rest API, Web Services, etc.) by converting characters to HTML entities, whitelist of allowed characters, sanitizing = filtering. Authorization: Verify the validity of the user session / token at each user action. Be sure to always validate permissions for each operation. Communication: Whitelist rather than Blacklist. Eg. explicitly permitted target with which application is allowed to communicate is the preferred option than list of forbidden targets that will not cover every possibility. Check: Minimize the user’s possibility to affect file paths when loading files. Avoid loading file depending on path set as a input parameter. In case of weak validation, the user could retrieve the system file from the server. Also do not be benevolent in file upload and check explicitly allowed file types.
Establish clear security policies - auth level, password policy, request repetition protection (unique token principle), bruteforce protection (captcha).
Require the recommended security headers Add headers in responses, at least HSTS, X-Frame-Options and also configure flags HttpOnly and Secure to key cookies.
Encrypt everywhere. - in db, on the way (https everywhere).
Can I receive an error from my app? Yes of course, but handle all error states by implementing custom error pages.
Don’t be afraid to use anti-CSRF tokens or JWT Session token, which will be stored in Local storage on client side.
Do not forget about the configuration. Turn off what is not necessary = unnecessary configuration pages (unneeded features, components, documentation and demos); change the default url of admin interface + default login; disable debug mode logging. Configuring an XML parser is important in way, that it does not support loading of external entities, which could lead to XXE (XML External entity) attack. This attack can result in confidential data being discarded, denial of service, server-side request forgery, port and file scanning from the computer’s perspective where the XML parser is running.
Hardcoded sensitive information should be handy for an attacker - avoid sensitive information in the comments in the code for test / production release, NEVER store credentials to comments or hardcoded into code.
Beware of Business logic flaws. Make sure that the user cannot skip any of the steps, bypass the validation on the client (eg edit the resulting price directly in the request …). This way, sometimes we manage to insure for 999999999Kč or buy for -50000Kč without registration.
3) WHAT NEXT?
Different environments? Yes, use the environments for DEV, TEST, PROD, but try to maintain an identical configuration.
Patch / Patch / Patch - This means = update also versions of the libraries used.
The penetration test should be part of the test phase of the new application release.
In conclusion: What to advise our company for future projects? “Developers are mostly stressed with focus on delivery schedule and finance criteria as the priorities”, usually sais responsible person for the company’s IT security. They are well aware of the fact that the remedies that arise later on from data leakage or in the better case, from the Penetration Test findings are much more difficult to repair than involvement the security perspective into design and development of web applications.
